-
Notifications
You must be signed in to change notification settings - Fork 788
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support bundling the raw Pages _worker.js
before deploying
#2404
feat: support bundling the raw Pages _worker.js
before deploying
#2404
Conversation
🦋 Changeset detectedLatest commit: ff4f52c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/runs/3901445415/npm-package-wrangler-2404 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/prs/2404/npm-package-wrangler-2404 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/runs/3901445415/npm-package-wrangler-2404 dev path/to/script.js Additional artifacts:npm install https://prerelease-registry.devprod.cloudflare.dev/runs/3901445415/npm-package-cloudflare-pages-shared-2404 |
This could definitely do with some docs changes, maybe as an addendum to https://developers.cloudflare.com/workers/wrangler/bundling/? Are the |
Codecov Report
@@ Coverage Diff @@
## main #2404 +/- ##
==========================================
+ Coverage 72.97% 72.99% +0.02%
==========================================
Files 156 156
Lines 9709 9735 +26
Branches 2556 2565 +9
==========================================
+ Hits 7085 7106 +21
- Misses 2624 2629 +5
|
By the way, I found that quite often the "integration" tests failed simply because they overran the default 5 seconds. It was completely non-deterministic and depended upon the workload on the machine and other random factors. I bumped up the timeouts on all the ones that tended to flake out to 10 secs. |
Pete, you're my hero. I'll try review this today. |
packages/wrangler/src/pages/dev.tsx
Outdated
@@ -78,6 +79,11 @@ export function Options(yargs: Argv) { | |||
description: | |||
"The location of the single Worker script if not using functions", | |||
}, | |||
"bundle-worker": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will make this default at some point pretty soon. So I'm tempted to make this an env var or deprecated/experimental or whatever so we can remove it easily when we force it. What do you think, @petebacondarwin ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, to keep in line with wrangler publish
we should keep this and call it bundle
. The usage in wrangler publish
is that this defaults to true but can be turned off with no-bundle
or bundle=false
.
So I would rather not hide it away - I think there may be valid cases where people choose not to run the bundler on the generated _worker.js
.
.changeset/tiny-knives-compare.md
Outdated
command line argument to `wrangler pages dev` and `wrangler pages publish`. For | ||
backward compatibility this flag defaults to `false` if not provided. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
command line argument to `wrangler pages dev` and `wrangler pages publish`. For | |
backward compatibility this flag defaults to `false` if not provided. | |
command line argument to `wrangler pages dev` and `wrangler pages publish`. |
If you're happy, I'd like to drop that line from the release notes since I will be doing this by default soon enough.
let workerFileContents = _workerJS; | ||
if (bundleWorker) { | ||
const outfile = join(tmpdir(), `./bundledWorker-${Math.random()}.mjs`); | ||
await buildRawWorker({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we not need to listen for onEnd
to complete here and in the checkWorker()
call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think onEnd()
is only really helpful when watch: true
, right?
Without watching the call to buildRawWorker()
will only resolve after the build completes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For watch mode, the returned promise resolves after the first build but then we need a way to be notified after subsequent builds.
515659b
to
4a7831c
Compare
43bfe20
to
c14ec54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing based on the nature of these changes it had to be little beefy PR. I would appreciate some of your time for a pair review on this one.
This is not as beefy as it looks. But that is my fault because I have wrapped a bunch of test changes into the PR that are not actually necessary for this PR. At the time of writing I had to make these changes to get the flaky fixture tests to pass, but I think with switching them to Vitest they probably are less flaky now. So you can mostly ignore the changes to all the After that, there is the addition of the |
fa796e3
to
c5a915c
Compare
I have split the PR into two commits to make it easier to see the main change from the test refactor. |
@petebacondarwin |
I would be happy with that. But in a follow up PR. |
cfdb351
to
a80a96d
Compare
LGTM! Only those 3 wording nits and this is good to go AFAIAC 🎉 |
Thanks for the explanation. Considering the fixtures, there is a lot less to the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR is already approved. Nothing I mentioned is blocking.
let runBuild = async () => { | ||
await checkRawWorker(workerScriptPath, () => scriptReadyResolve()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codecov is mentioning these lines are uncovered by tests? Is this covered in the fixtures rather than the wrangler package tests (Codecov doesnt collect fixtures tests I think)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is covered by fixtures tests.
@@ -278,47 +295,39 @@ export const Handler = async ({ | |||
}); | |||
} else if (usingFunctions) { | |||
// Try to use Functions | |||
const outfile = join(tmpdir(), `./functionsWorker-${Math.random()}.mjs`); | |||
scriptPath = outfile; | |||
scriptPath = join(tmpdir(), `./functionsWorker-${Math.random()}.mjs`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not part of your PR, but wouldnt it make more sense to have this idempotent by hashing someting dynamic and unique to the functionsWorker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't really matter what the name is as long as it is unlikely to collide with another concurrent build. This was the simplest solution.
We now use helper functions to setup and teardown a long-lived wrangler process. This means that we can remove the `--forceExit` option from the jest setup.
Previously, if you provided a `_worker.js` file, then Pages would simply check the file for disallowed imports and then deploy the file as-is. Not bundling the `_worker.js` file means that it cannot containing imports to other JS files, but also prevents Wrangler from adding shims such as the one for the D1 alpha release. This change adds the ability to tell Wrangler to pass the `_worker.js` through the normal Wrangler bundling process before deploying by setting the `--bundle` command line argument to `wrangler pages dev` and `wrangler pages publish`. This is in keeping with the same flag for `wrangler publish`. Currently bundling is opt-in, flag defaults to `false` if not provided.
a80a96d
to
faa10bf
Compare
@petebacondarwin is there a docs PR that should be linked to this? |
Ah sorry. I missed this comment. |
What this PR solves / how to test:
Adds support to
wrangler pages
to pass the raw_worker.js
file through the normal Wrangler bundler,which improves support for D1 bindings with web frameworks that generate this file, such as SvelteKit.
You can test whether this is working by creating a Pages project with a
_worker.js
that imports from anotherJS file. E.g.
_worker.js
dep.js
Associated docs issues/PR:
Author has included the following, where applicable:
Reviewer has performed the following, where applicable:
FIxes #2153